Phase: Supporting Processes

Often TMap test process is organised in projects but in addition to this projectbased approach, testing (or parts thereof) can also be organised on the basis of a line organisation. More and more organisations opt for this alternative. This can be explained based on the four developments which can be summarised as ‘more for less, faster and better’.

These developments have an impact on all disciplines within the playing field of IT. For instance, new (highly advanced) development environments are created for programmers, allowing for the relatively simple and fast design and build of complex software. Also, new (iterative) development methods emerge that assume far-reaching interaction with the users, resulting in, among other things, a significant reduction of project lead times. Moreover, management aims more and more for reuse of (internal and external) components that must be integrated into the existing IT architectures.

In short, more is built and maintained in IT these days in the same time as used to be the case. The result is a lot more test work. In addition, creating the right test approach for the IT has become far more difficult because the IT has become more extensive and complex. Combined with the increasing attention for quality in organisations, this means that the relative share of testing in IT is on the increase.

As a result, management often feels that testing, with all of the related resources, is a costly matter. Other complaints are that it takes too long and that the quality of the process is disappointing. The TMap process has a number of process elements that recur in each test. For instance the concrete activities relating to setting up a test organisation, test environment, or the deployment of test automation. But other activities, like gaining test experience, learning the test object, or defining the standards used, also recur in every testing programme. In a project-based test approach, these elements are set up for the duration of the project. Moreover, the organisation works with project standards that are often created at the beginning of the project. This results in start-up costs. Furthermore the learning effect will be limited when working with temporary personnel. The knowledge and experience gained is largely lost at the end of the project. And the test environment, which was created with such effort, is dismantled. A project must also be completed within budget and the predefined planning. This means that there is little concern for executing activities that do not yield a return on investment (ROI) within the framework of the project. Setting up testware for reuse is an activity that has little or no interest, while a structured test approach like TMap requires it.

As such, this is clearly not an optimal situation focusing on controlling costs, time and quality. A solution to this problem is assigning the execution of these set process elements in TMap to a line organisation. Such a line organisation is then called a permanent test organisation. It ensures that the knowledge concerning these process elements and the associated products is retained, and activities with a longer ROI time can be developed. When projects want to use one of the process elements (such as a test environment, using test tools or standard templates), they can be acquired as a service from the permanent test organisation.